home *** CD-ROM | disk | FTP | other *** search
- Path: newsfeed.internetmci.com!xmission!news
- From: tknarr@xmission.com ( Todd Knarr )
- Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.edu,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3
- Subject: Re: Hungarian notation
- Date: 10 Jan 1996 05:06:18 GMT
- Organization: Chaos Central
- Message-ID: <4cvhga$5rn@news.xmission.com>
- References: <30C40F77.53B5@swsbbs.com> <30EF0415.6FE1@tus.ssi1.com> <1996Jan7.045815.8676@ohstpy> <4cpb00$nqk@news.xmission.com> <4crm6i$24mi@navajo.gate.net> <4csi2t$gsa@news.xmission.com> <4ctomq$1pi8@hopi.gate.net>
- Reply-To: tknarr@xmission.com ( Todd Knarr )
- NNTP-Posting-Host: slc133.xmission.com
- X-Newsreader: IBM NewsReader/2 v1.2
-
- In <4ctomq$1pi8@hopi.gate.net>, feathers@gate.net (Michael Feathers) writes:
- >This may seem like a quibbling point, but in OOP it should be a natural
- >assumption (because of polymorphism) that all objects of derived
- >classes should perform in a manner appropriate to their class in
- >the context of their base classes interfaces. This is information
- >hiding, in much the same way as function names hide implementation
- >yet provide semantic information. If this is not the case, then the
- >inheritance should be suspect.
-
- Except that, if you tell people that the prefix on the name tells the
- type of the variable, they may believe you. If they do, in the case
- of my example, they might well say "Oh, the prefix says that's a Stall."
- and merrily proceed to locate the Stall class and begin working with
- it. If they are not intimately familiar with the design of my code
- ( which they may not be, work assignments tend to be handed out based
- on who is available rather than who is most familiar with a given bit
- of code ), they may assume they can trust the prefix to be right and
- skip checking the prototype, the class heirarchy and the like and go
- right to the class that the variable *says* it is rather than finding
- out what it *really* can be. The end result will be, at the very best,
- a simple failure of their changes to work. At worst they'll have a
- 16 megabyte core dump on their hands.
-
- >Why never a Stall? If Stall's interface is present in any of its derived
- >classes, Stall calls should be resolved.
-
- Simple: Stall is merely the base class, and objects of it are *only* created
- during program initialization as a bookkeeping device to keep track of
- information while the program determines the actual current status of the
- shower stall the Stall object represents.
-
- Once you get into the subclasses, you get serious behavior differences.
- For instance, Stall objects do not respond to changes in the physical stall
- they represent. The routines are there, but they merely return. Each
- subclass implements different behavior to a different set of changes, as
- appropriate.
-
- >True enough, but I think that new OOP programmers should drill it into
- >their heads that references==pointers as far as polymorphism goes (and
- >in other ways too). Polymorphism has to change the way that you understand
- >code. We are not in Kansas any more.
-
- Assuming they check the prototype and then check the class heirarchy to
- determine that they are dealing with a polymorphic type. As I said, this
- conflicts with HN's theory that the prefix of the variable name itself
- accurately reflects the actual type of the variable. This is exactly the
- same situation as I run into with comments. Accurate comments are a
- blessing, but the only thing worse than no comments at all is lots of
- comments that don't reflect the actual code. If you have no comments at
- all you automatically know you need to read the code, but if you have
- lots of comments that are wrong but that you are told you can believe,
- you may make the mistake of believing them at the wrong time and wind up
- wasting two weeks wondering why your changes keep breaking the code when
- according to the comments they shouldn't.
-
- Yes a good programmer should check first. In an ideal world, all programmers
- will. In the real world, though, somebody who's never seen the code before
- gets told to make a major change to it and have it ready for release by
- Thursday, and they've already got 4 other high-priority projects they need
- to get finished, and checks to make sure what you are told is true really
- is true sometimes get skipped. My experience is that every single time
- that happens I get bit by it, so I tend to avoid things that would increase
- the number of places that could happen.
-
- --
- Todd Knarr : tknarr@xmission.com | finger for PGP public key
- | Member, USENET Cabal
-
- Seriously, I don't want to die just yet. I don't care how
- good-looking they are, I! don't! want! to! die!"
- -- Megazone ( UF1 )
-
-